Advancing Cloud-Native Cybersecurity Using eBPF – Matt Richards, Aqua Security

This is Textron TV. Hey guys. Thanks from the throw.

We're here with Matt Richards. Who's the chief marketing officer for aqua security. We're going to be talking about ebpf and the impact that's going to have on security and then in general what's going on in the overall Marketplace?

Hey, man, welcome to the show. thrilled to be here Mike See you guys are one of the earliest people that I've seen so far who's kind of tapping into this new micro kernel architecture that's available in Linux or running a whole bunch of things faster, but why don't you walk us through exactly what you guys are up to and what the implications are for security folks. Hi, I'm happy to let's just add a high level if you say what is aqua.

Do we like to say we stop Cloud native attacks? In other words, we're stopping attacks on your Cloud native applications. Prevention right before production of course, and then also as attacks happen in production and to do that.

You have to have as non-intrusive way as possible. But still be in the container. to block attacks in real time in production and to do that we Leverage The CBP of framework and essentially what we're doing is we're tapping into another way to think about as a probe into the kernel in modern Linux distributions that give us visibility without dropping our own code into the kernel, right?

So this is essentially a feature of modern Linux distributions this ebpf probe and you can it's essentially hook where you can insert code to do things in a faster more efficient manner than you would otherwise have done in the past where you had to insert your own code to get that same level of visibility at the kernel. And so what we do with that that's like you can see what's going on. We've created we can talk about our research team a little bit later, but we've created a whole range over 200 definitions of Behavioral indicators of attack not signatures, right but behaviorally indicators of say what goes on in a root kit exploit so we can actually identify that a rootkit has been installed and is intercepting calls to list directories for example and try to keep itself hidden.

And by understanding that that behavior is happening through the ebpf probes. We can identify and block. the root kit attack in real time and it really And this is important because it seems like as people deploy more and more containers.

The existing platforms are struggling with the volume and keeping Pace with all of that. So is this going to be critical for just securing Cloud native environments and scale? 100% what's happening?

Is you're seeing? Two elements in the market today, right? There's the see it which is a necessary first step.

And then there's the stop it which is the second step. and evpf gives you a very interesting way today to see it. And then to stop it, right?

That's when we have to we actually deploy some of our proprietary capabilities there to actually stop those attacks in real time in production and then to do that at scale. You need most accurate lowest impact on any given container, right? Because the overhead can.

Start to chew up excess capacity in your in your Cloud. So as you think about automated detection. This is the scale element.

Identifying behaviors and achieving 90, you know, let's call it. It's called 80% coverage out of the box. This is we just released our lightning and Porsche last week and it's leveraging the ebpf framework and that's exactly the intent is to make it super fast and easy to deploy and get good coverage.

out of the box with no customization and that's what the behavioral detection can give us and you can get that deployed very quickly into production very low risk and be protected. Kind of sounds too. Good to be true, right because normally it's the other way around.

Do you think that people are appreciating the nuances of cloud native security? Some people would argue that these applications are more secure than monolithic other people say they're more complex and more challenging to secure either way. It seems like it's fundamentally different in our people rap in their minds around exactly.

What is different about Cloud native security. It's it it's very different and I think if you you go back to the days when I started Coating in Java and see. It was a monolithic slow waterfall development process months between releases of now.

We're talking minutes between releases. There are banks that refresh their entire infrastructure every day by just reloading everything from their repositories to ensure that there's no malicious code install. we have Multiple pipelines where maybe we had a dozen there's you know 10x that number of pipelines today.

Micro Services being deployed that are then leveraged and knitted into applications open source is now very common. And of course, it's also a very good supply chain attack. software supply chain attack, so You need to understand the whole.

scope of a cloud native application What is the cloud native application containers kubernetes Lambda fargate hosted containers openshift? Right? That's a cloud native application is an application built to take advantage of.

Of all of those new containerized capabilities, that's part one is that different? Radically you have developers defining the infrastructure in code. In development, that would get deployed at runtime.

That's never happened before. So you no longer have to plug and play firewalls that we used to have to. Right.

Now you're actually deploying code and defining and software like your network segmentation so you can catch the errors earlier in code if you're watching. So that's why when you think about Cloud native security, why is it different because you need to think about the entire scope from code all the way through to production. from the infrastructure through the process to the actual code itself and you need to secure all of that and that's what we do at aqua and that's what that's what Gartner calls a cnap.

or a cloud native application protection platform who's responsible for all this these days and I'm asking the question because historically the security people tend to view. This is a application security issue that developers was supposed to fix developers thought the security guys for fixing in and nobody did anything in the middle. So the question I'm having is is that changing are we starting to see a greater appreciation for cloud native application security and who's leading the charge?

100% seeing in a change in who owns it obviously devsec Ops in that move starts to bring all these pieces together, but even for folks who aren't quite ready to make that transition we're starting to see the the security organization responsible. for the result So and that was even true. It was even true before but it was a lot easier.

When it came to Cloud native, it was just wasn't deployed as far so it was a lot of easier to think. Okay Cloud native is really for development. It's for testing, but we're not going to be in production.

Well now we're in production. I believe that 95% of all new applications are going to be built using Cloud native Tech in the next two or three years and that's basically all of the new stuff. and in that world and it's and it's the deployments are happening faster.

They're getting into production faster in that world. We're starting to see the cisos and the security organizations having to be responsible. when you think about but having to be responsibly responsible, right because if you put a gate or a circuit breaker in a development pipeline to keep out of vulnerability like the latest open ssl3 or log for J.

And you block that from production. You've now blocked the work of a development team, which could be quite large. I'd say so it can no longer be in isolation.

And what's happening is as folks Embrace Cloud native. Security is becoming part of the story and it's becoming an integrated devsecops. Capability and a lot of folks come back to us after.

deploying what we do and they say look you helped us get to devsecops because you gave us a single source of Truth in one platform across the entire process. Which helps us to speak the same language helps us understand that the nature of our vulnerabilities keep them out of production zero days in production. And the fixes back and through the cicd.

pipeline back to back into code is that starting to happen where we're starting to see the security platform that's used on the pre-production side is essentially the same as it is in the production side to facilitate those workflows. And is this also part of some larger consolidation effort? We're starting to see in the market.

I think that that last part also comes to with some of the economics that we're seeing in the market out there today. We're seeing a push towards that very same consolidation. Why well cost saving why have five scanners cross the lifecycle of an application when you can have one.

And so why at not only does it introduce five different answers and the arguments right? But it's also the cost of maintaining the five different. Vulnerabilities and vulnerability scanners an image scanners and that's different from a runtime snapshot scanner, which is different from you know, the agents that are actually protecting it in real time.

No, it should just be and when I what we're seeing is that the interest in from Dev all the way through to production that single answer one source of Truth a scanner. That can see and understand what's going on in infrastructure as code in your cloud service accounts in your images in your artifactor repositories in running images. It's all the same scanner.

And we're starting to see that consolidation. And and that's the direction. We've been heading actually as well, but we're seeing security organizations Dev organizations coming together and trying particularly in this economic circumstance trying to solve it with one tool rather than several.

Hmm you guys put together a 1 million dollar warranty last summer. That's kind of Brave in this world that we live in so what exactly the details of that and and one of the how would anybody actually tap into that if the situation never arose so it's yeah, we put it together last summer. We launched it out.

We were the first in the in the cloud native world to offer and really stand behind the product. And we don't know a better way to say look. We guarantee this with a warranty.

You will be protected in production. And so essentially we're looking at. If you're in production fully deployed, you know and manage right?

You need to make sure you have the latest you latest vulnerability databases, right? So to best practice management of the platform if you're a tax successfully. We agree then.

Yeah, we will We warranty that and we will up to a million dollars. Based on the number of containers in the size of the impact up to a million dollars on it and what we've seen is interest. a lot of interest around standing behind the product with a full warranty and that's not something we see in this space before and there's a couple reasons why we believe we can do it.

And that's built on our open source, right? We have them a world's best open source scanner. It's called trivia and aqua trivia and it is the number one most popular scanner in the cloud native chain all the way from code to to production.

So that's one piece there hundreds of thousands of users every day hundreds of millions of downloads. And the other reason is some of the behavioral research in the team Nautilus I alluded to earlier. But here's a team that's sold job is researching Linux based.

Cloud native attacks and what we found there's a lot of really interesting stuff we found in there but suffice it to say that's what standing behind the warranty and that's why we know we can that's why we make that guarantee. So what's your best advice to folks about how to achieve this convergence of developers and security folks who I just throw them all in a room and lock the door. It'll somebody comes out when irrational answer or is there some other set of best practices you're starting to see people employee.

Yeah, I think. There are two sort of two paths as you say throw them in a room or the more measured path, which is look. See it first.

So for me and when we talk to customers and with what they're doing generally speaking, they're sort of there's that there is to see it first, but see it across the entire. Life cycle from code all the way through to production see your environment. And one of the biggest questions how many containers you're running?

And the answer can often be I'm not sure. Which is why and where are they running? I'm not sure which is the basis for solving that problem is is where this end and code all the way through production.

Scanning comes from something like the first devices see it. See it but see it with the same tool in the same eyes. Across the entire life cycle so that you can identify the compound risks across a life cycle.

Right? So it's one thing to have a log for J in production. But if that application has no internet access like how big of vulnerability is that?

Versus right clearly it's a vulnerability. But how big a risk and how big a priority is it versus? Production running workload with malware that it's accessing the internet like that's a whole different animal.

And so you need to see that compound risk across the entire eye Cycles. So that's step one. and then step two is when you're comfortable and you understand it is now let's let's try to Because that's Step One is where you're going to get your Dev working with security working with Ops together speaking the same language.

And then once you're there, then let's work on stopping it stopping it pre-production. With with Stage Gates or circuit breakers if you will in the release process so that you're identifying and keeping bad known bad out of production and then let's do real-time protection. In production and that's so it's step one.

See it step two. supply chain step three runtime All right, folks says always if you can't see it. You can't secure it.

The trouble is with those pesky little containers is they're only around for a couple of seconds, but you'd be amazed at how much damage can be done in a few seconds. Hey Matt. Thanks for being on the show.

Happy to be here. Thanks, Mike. All right back to you guys in the studio.